Musings, "It Works On My Machine"

I’m a little old school. Setting up my development environment is, as least for me, a relaxing experience. I like to take my time with it. It’s an opportunity to peer into the black box of what makes to build work and our applications run correctly - a chance to start something (anything!) from scratch when the rest of the day is going to be largely predictable.

If I were to compare it to something real world — it’s like washing the dishes by hand when the dishwasher is working perfectly fine. Needless to say, it’s pointless but there’s something oddly satisfying about the ritual. It’s a chance to engage with the process, to feel like you’re in control of the tools and the environment you’re working in, even when it’s not strictly necessary. It’s the difference between being a passenger and the driver — even if the car can drive itself.

The truth is, it’s probably more about the mindset than the actual setup. You learn a lot about your environment — the quirks, the hidden shortcuts, and the things that often go unnoticed when everything is automated. Every decision, every configuration tweak, is a small, intentional choice. And when it all finally clicks together, it feels a little like building a machine that just works — and you made it happen.

Sure, it takes more time than simply cloning a repo and firing up a container. But it gives me a sense of ownership, a connection to the process that’s hard to get from just pressing a button. It’s like writing a letter by hand instead of sending an email. Both get the job done, but one feels like a more personal experience. What’s more when something goes wrong, that intimate knowledge of the internals pays dividends when you know where the pains likely come from.

Now, on the other hand, saying “It Works On My Machine” is just not an option for an experienced developer to say to a junior one. I’ve seen countless occasions where the new guy or gal has spent ages setting up a new development environment only to find things fail when they try to get things running. Even with the most beautifully written technical onboarding documentation (I’ve written my fair share) or tooling to automate setup steps (I’ve built those too!), the newbies or interns seemed to struggle with the setup and sit frustrated and unproductive.

This is where tools like devcontainers, or nix environments come into play, and why I’ve come to appreciate them. They offer a solution to a problem that has plagued development teams for years: ensuring consistency across environments, particularly when working with new developers or tooling upgrades.

Instead of each developer having to meticulously configure their machine — installing dependencies, adjusting configurations, and navigating the inevitable mismatches that come from different operating systems, versions, or local settings — a devcontainer defines a single, unified environment. The beauty of this is that it’s not just “this works on my machine” anymore. It’s “this works on every machine.” When a new developer joins the team, they don’t have to spend days wrestling with their local setup just to get the app running. They simply open the project in VSCode (or one of it’s many, many forks), the container spins up, and they’re immediately working in the same environment as everyone else.

This doesn’t just save time. It also reduces a lot of frustration. Instead of newcomers feeling like they’re chasing elusive setup issues and a weird badge of honor, they can dive straight into the code. For me, that’s a huge win. They can focus on learning the actual application, improving their skills, and contributing — rather than feeling stuck in an endless loop of dependency conflicts and configuration failures.

Just musing…